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1. Introduction 


Transmission Control Protocol (TCP) (Postel, 1981) is the vastly researched, used and 
implemented transport protocol from the bouquet of standardized protocols we have. Since 
its first introduction, TCP has experienced tremendous revolutions specifically regarding 
the way it should control congestion (Allman et al., 2009). Many TCP flavors exist, one 
can control its sending rate according to link bandwidth estimation like in the Westwood 
variant (Mascolo et al., 2001), while another tunes its congestion window (cwnd) based on the 
round-trip time (RIT) evaluation such as TCP Vegas (Brakmo & Peterson, 1995), just to name 
few examples. However, all of these TCP versions assume a bulk transfer of data and thus 
they are optimized upon this type of traffic. 

On the other hand, Air Traffic Management (ATM) data traffic has other characteristics than 
file transfer. Messages generated from aeronautical services are triggered by events in the 
aeronautical environment. Further, these messages have bursty inter-arrival times, which can 
go up to several minutes, relatively small size mostly in the order of few hundreds of bytes and 
a maximum delay (a maximum of few seconds) that they have to be delivered within. As can 
be realized, a TCP source may experience some inactive periods due to the burstiness of the 
traffic. However, in (Jacobson, 1988), it is recommended that to control and avoid congestion, 
TCP should use slow start mechanism when restarting a transmission after a ratherly long 
idle period. 

The NEWSKY project (NEWSKY, 2009) recommends to design a transport protocol for 
avionics which is based on the User Datagram Protocol (UDP) but with reliability 
measures. Taking these suggestions into account, the Reliable User Datagram Protocol 
(RUDP) (Bova & Krivoruchka, 1999) is an interesting option. However, it has features 
from TCP, which are not desirable for the ATM context, like connection initiation and 
shutdown, congestion control and byte streaming mechanism, which according to the authors 
of (NEWSKY, 2009) and (Muhammad & Berioli, 2010) reduce the performance of a transport 
protocol when transferring small files. Therefore, RUDP could be a highly qualified candidate 
to transport aeronautical traffic in case it is carefully re-designed and adjusted to consider the 
properties of an ATM traffic over highly asymmetrical links. 

Furthermore, in the context of checking the validity of TCP to transfer messages of ATM 
services, questions related to the performance of the protocol will be addressed. For example, 
the relation between the cwnd of TCP, aeronautical messages and congestion control. 

The Seamless Aeronautical Networking through integration of Data links, Radios and 
Antennas (SANDRA) (SANDRA, 2011) concept consists of the integration of complex and 
disparate communication media into a lean and coherent architecture. SANDRA as a project 
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is divided into several sub projects (SPs). This work belongs to the one dealing with 
seamless networking specifically for the transport layer protocols and performance task. 
Transport layer protocols should be assessed with respect to their suitability for aeronautical 
communication and their impact on the system availability and reliability. Finally, an 
optimization for these protocols in order to be used in avionics context should be provided. 
The work in this chapter is organized as follows. In the next Section, an overview about the 
aeronautical services is presented. In Section 3, the system architecture design in which the 
protocol will be operating is discussed. Section 4 explains some properties and illustrates few 
drawbacks of using TCP in avionics from theoretical and technical perspectives. The RUDP is 
further investigated in Section 5 where adjustment recommendations are given. In Section 6, 
detailed analysis of the ATM traffic pattern is shown and suggestions on system design are 
provided. Finally, a conclusion is drawn in Section 7. 


2. Aeronautical services 


The currently operating Aeronautical Telecommunication Network (ATN) protocol is based 
on the ISO/OSI stack and uses the TP4 protocol (ITU-T, 1995) via Dialogue Service (DS). 
However, the future envisaged protocol is expected to be based on the IPv4/v6 protocol stack, 
as identified in (NEWSKY, 2009). 

The study of potential future communications technologies to meet safety and regularity of 
flight communications requirements, i.e. those supporting Air Traffic Services (ATS) and 
Airline Operational Control (AOC), have been initiated by the European Organization for the 
Safety of Air Navigation (EUROCONTROL) and the Federal Aviation Administration (FAA). 
The second version of the Communications Operating Concept and Requirements (COCR) 
document (EUROCONTROL & FAA, 2007) identifies the requirements placed on the 
communications that take place between the aircraft and ground radios, i.e. the air-to-ground 
(A/G) and ground-to-air (G/A) links. Further, the COCR divides the airspace into five 
domains. Thus, ATM services vary according to the domain in which the position of the 
airplane will be. Figure 1 illustrates the airspace domains, which are: 


e Airport (APT) consists of the airport and the close area surrounding the airport. 
e Terminal Maneuvering Area (TMA) also surrounding the airport but on a larger scale. 
e En Route (ENR) is the continental or domestic airspace used by Air Traffic Control (ATC). 


e Oceanic, Remote, Polar (ORP) is the same as ENR but it covers geographical areas 
generally outside the domestic airspace. 


e Autonomous Operations Area (AOA), in this block of airspace, the airplane is 
self-separate, i.e. ATC is not used. 


The corner stone of this work is to introduce a reliable communication environment for the 
ATS and AOC services. The ATS applications are the most critical for the safety of the flight. 
They involve the messages between the cockpit and the control center, i.e. the ATC center 
in the airport. Paired to these services are the AOC, which are primarily concerned with the 
safety and regularity of the flight. AOC applications are responsible for the communication 
between the aircraft and the AOC center, company or operational staff at an airport. 

The messages generated by these applications have inter-arrival times in the order of seconds 
up to several minutes. Moreover, each message has a maximum latency time that it has to be 
delivered within. Typically, this time is lower than a message inter-arrival time. It is also worth 
to mention that the ATM traffic is inelastic; this means that these services cannot adjust their 
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Fig. 1. Airspace domains as envisaged by the COCR document, namely, APT, TMA, ENR, 
ORP and AOA 


message generation to the network conditions but they require a minimum level of resources, 
see (EUROCONTROL & FAA, 2007). 

Within the COCR document, there are 32 ATS services, 21 belong to AOC and 2 NET services. 
The messages generated by these services have relatively small size with respect to a common 
file on the Internet. For example, the FREETEXT message is only 377 bytes. This service 
represents a textual message between the cockpit and the AOC center. Very few messages are 
of kilobytes size. The shortest message size is 82 bytes while the largest is around 21 kilobytes, 
which deals with the weather reports and is called WXGRAPH. Section 6 will present detailed 
analysis about the aeronautical traffic pattern. 


3. System architecture 


The trend in the aeronautical sector, driven by an increasing number of flights, is 
the introduction of new communication services and the transition of the ATM from 
analogue techniques towards digital communication services results in the development 
and deployment of new and heterogeneous link technologies, see (Kissling, 2009). One 
example of a link technology under development for direct A/G radio communication 
is the L-band Digital Aeronautical Communication System (L-DACS)-1 communication 
standard (Brandes et al., 2009) and (Graupl et al., 2009). Another example is the European 
Space Agency (ESA) Iris programme (ESA, 2009) using satellite communications, which is 
currently under development. The new link technologies will complement the existing ones 
(like VHF Digital Model (VDL)-x) and will also coexist with future, short range links such as 
WiMAX as part of the communication infrastructure in the APT area. The system architecture 
under consideration in this work requires the aircraft to have several link technologies 
available for communication with the ground, which all have heterogeneous properties. 
One of the most important properties changing with the link is the propagation delay with 
RTTs in the order of 500ms for GEO satellites down to few milliseconds for direct A/G 
links. Besides the delay, the communication bandwidth and datarates change as well with 
the links, starting with few bits per second and reaching higher datarates with kilobits 
per second. Finally, also from the channel characteristics, packet error and loss rates may 
change with the link technology. The integration of these different links into one network 
results in a system architecture as illustrated (simplified) in Figure 2. As shown there, 
only the ATS and AOC services are considered. Each of these services may have one or 
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Fig. 2. System architecture 


several End Systems (ESs), which generate and receive data messages. A data message is 
transmitted via the airborne router as one or several IP packets over a link with a specific 
link layer and physical layer protocols belonging to the selected Link Access Equipment 
(LAE). On the ground side, the network layer IP datagrams are then routed via the ATM 
ground network (assumed as a backbone ATN/IPS network) towards the correspondent 
ES in the ground network. For safety related operational services ATS and AOC, reliable 
message transmission is a key demand since loss or corruption of messages can have severe 
consequences. Transport layer protocols, which shall guarantee the reliable transmission of 
data should work efficiently over all different link technologies present. For provision of 
transmission reliability in the future ATN/IPS network, up to now the TCP protocol has 
been envisaged (ICAO, 2010). The different conceptual options to use the TCP protocol 
and the requirements to a transport protocol have been reported in (Kissling & Graupl, 2008) 
and (Ehammer, Graupl, Rokitansky & Kissling, 2009). In (Kissling & Baudoin, 2008), different 
possibilities for protocol stack architectures in the ATM scenario have been investigated. The 
major key issues for using transport layer protocols in the ATM environment found in this 
work were the provision of a reliable communication service which makes best possible use of 
the scarce communication bandwidth and does not require coexistence of different transport 
layer protocols in parallel. Deployment of several link-specialized transport protocols 
in parallel would cause higher cost for maintenance, management and especially for the 
standardization procedure which every transport layer protocol has to go through. 


4. Transmission control protocol 


TCP is the commonly used protocol by many of today’s Internet most popular applications 
like Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP). It provides 
reliability and ordered delivery of a stream of bytes being transmitted from a program on 
one computer to another over an unreliable network. 
TCP is a connection oriented protocol. That is, a connection should be established before 
sending data. Depending on the RTT between the two communicating nodes, a waiting time 
of: 

Tw = 2-RIT (1) 
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is measured before receiving the first byte of any actual information. 

The work done by (Ehammer, Graupl, Rokitansky & Kissling, 2009) describes several 
possibilities on the way that TCP could be operated over aeronautical networks and showed 
the advantages and drawbacks of each method. These methods deal with the multiplexing 
or not of the ATM services and the network layer interaction. These techniques are: (a) 
re-establishing of connections for each transmission and for every service (Figure 3(a)), 
(b) establishing a connection once for each service and keep it open (Figure 3(b)), (c) 
re-establishing of the connection for each transmission of a multiplexed set of services 
(Figure 4(a)) and (d) establishing a connection for a multiplexed set of services and keep it 
open (Figure 4(b)). 
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Fig. 3. Transport layer session connection establishment/shutdown with no services 
multiplexing 
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Fig. 4. Transport layer session connection establishment/shutdown with services 
multiplexing 


Further, in (Ehammer, Graupl & Rokitansky, 2009), the authors discussed several well known 
TCP optimization techniques and found out that for TCP to operate over aeronautical 
communication network, a minimum of a certain link capacity should be available per user, 
else TCP will run into performance problems. 

Moreover, within the aeronautical environment, where the messages to be transmitted in 
a flight are scarce, maintaining a single TCP connection is cumbersome. This is due to 
the fact that within a flight the aircraft will change various links with different capacities 
and delays, giving rise to links handover management overhead. In (Daniel & Kojo, 2008) 
and (Daniel et al., 2008) the authors had developed cross-layer assisted TCP sender algorithms 
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to reduce the unnecessary packet retransmissions and congestion control actions due to 
vertical handovers. In other words, they developed mechanisms to help TCP to reduce 
retransmission overhead when operated in wireless environment, in which handovers may 
occur on events such as the links properties are interchanged between high/low delays, 
high/low bandwidth or upon retransmission timeouts (RTOs) during disconnection. 

On the other hand, allowing TCP to establish a session for every transmission brings 
three disadvantages. Figure 5 illustrates this approach in comparison with the single TCP 
connection (discussed previously). First, for every message to be received, Tw should be 
waited before the first bit of the actual data delivery, which affects the delivery time of the 
message. Secondly, the overhead introduced by TCP, because of the connection initiation and 
shutdown is on average large compared to the sizes of the messages produced by the ATM 
services. Finally, the cwnd of a TCP sender will not be able to capture the congestion status 
when operating below aeronautical services because of the traffic pattern they adhere. 


Connection - . i i 
) establishment 5 r ae k Aeronautical 
& shutdown jandover + message 


Fig. 5. Transport layer (TCP) connections as envisaged in (c) and (d) 


In (Muhammad & Berioli, 2010), we developed a model to theoretically estimate the overhead 
produced by different transport protocols when transferring a file. The investigations showed 
that for small file sizes, reliable, connectionless transport protocols with no congestion and 
flow control have the lowest overhead cost. In this work, we extend the model to measure 
the overhead produced by the connection establishment and shutdown mechanisms of TCP. 

According to the specification of TCP in (Postel, 1981), to start a session, a client should 
send a SYN packet to the server that will respond with a SYN — ACK and finally the client 
will confirm with an ACK (3-way handshake). On the other hand, when the server finishes 
transferring the file, it will send a FIN packet, and the client will reply with an ACK. Further, 
when the client makes sure that it has the complete contents of the file, it will send another 
FIN to the sender and wait for the ACK packet. These two mechanisms are bi-directional 
and thus we split our model based on the forward (FW) and return (RT) channels, respectively. 


SEW = Hsyn—ack + Hrn + Hack, (2) 
SRI = Hsyn + Hen + 2° Hack 


where see and ae are the sizes of the overhead on the FW and RT channels, respectively. 
Moreover, Hx is the size of the header of the packet X, bearing in mind that TCP connection 
establishment and shutdown packets are only TCP headers. 

Now, the overall overhead related to a connection start and end in TCP amounts for: 


He = SEW + SRT (3) 
Therefore, the TCP session overhead produced for a file of size F is: 


OHe = ac (4) 
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Fig. 6. Overhead estimation of a TCP connection establishment and shutdown 


The two plots in Figure 6 show the overhead generated for different message sizes and the 
overhead cost for transmitting the same file multiple times with different TCP connections. 
For this simulation, we used the minimum TCP header size (20 bytes) assuming no options are 
used. In Figure 6(a), we show the connection overhead percentage (on the y-axis) generated 
for different sizes of messages in the range of the ATM services messages size (x-axis). Here, 
we assume a single message is transferred in a connection. As can be clearly seen that the 
overhead of sending a message of small size is considerably large. 

Moreover, Figure 6(b) represents the overhead generated for multiple file sizes with several 
TCP connections. For instance, when simulating a file of size 10 kilobytes, the x-axis represents 
the number of transmissions of that file each time with a new connection initiated and 
shutdown. As it can be realized, the higher the number of transmissions, the higher the 
overhead. Conversely, the larger the file, the lower the overhead. 

Taking the complete traffic profile characteristics into account and not a single message as 
above, Figure 7 shows the cwnd (displayed with a line), in bytes, of TCP versus the actual 
transmitted bytes (represented by stars). It can be clearly realized that the cwnd of TCP cannot 
cope with the real transmitted information. We can say that the cwnd of TCP was deceived by 
the incoming application data. Thus, it shows a very oscillating behavior and this is related 
to the long idle periods between two consecutive transmissions, which is associated with the 
inter-arrival times of the ATM messages. Further, the average size of this cwnd (reflected by 
the dotted line) is very close to the value of the average cwnd resulted in the simulations done 
by (Ehammer, Graupl, Rokitansky & Kissling, 2009). 


5. Candidate protocols 


In the summer of 1984, the standardization of the Reliable Data Protocol (RDP) was held 
by (Velten et al., 1984) with the idea of running applications such as remote loading and 
debugging. Six years later, their colleagues at BBN Communications Corp. updated the 
standard with a newer version (Partridge & Hinden, 1990). In short, RDP is connection 
oriented and offers reliable transport to efficiently support the bulk transfer of data. 

Moreover, based on these two standards with the same protocol properties, RUDP defined 
in (Bova & Krivoruchka, 1999) (IETF Internet-draft) extended the primitive! UDP (Postel, 


1 Because, according to the authors, TCP is too complex. 
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Fig. 7. cwnd of TCP vs the actual transmitted bytes from the aeronautical services 


1980) with window and flow control, acknowledgement mechanism, retransmission of 
packets lost on the way and avoidance of buffer overflow in order to transport telephony 
signaling. 

As mentioned in Section 2, each aeronautical service sends a different message. The 
generation of these messages is triggered by events. The services at the two ESs, i.e. the 
airplane and the control center, send their messages independently. Further, the generated 
messages differ significantly among each other in terms of message arrival time, size and 
latency requirements. However, almost all of them require reliable delivery service by the 
transport protocol. Some services do not require full reliability like surveillance ones because 
they are generated more frequently, see (Ehammer, Graupl & Rokitansky, 2009). Thus, a 
reliable transport protocol to be designed should be aware of the properties of these messages. 
Figure 8 illustrates the protocol stack using the provisioned transport protocol above the 
Internet Protocol (IP) layer that takes care of the addressing and below the aeronautical 
services labeled Aj, Ap,..... An aeronautical transport protocol should provide reliability, 
ordered delivery and honors message boundaries like UDP. Further, it should be IP based 
and connectionless transport protocol in order to reduce the session initiation and shutdown 
overhead. Finally, it should be able to cope with highly asymmetrical communication 
channels such as satellite links. 


Fig. 8. The protocol stack to be used by a reliable transport UDP-based protocol such as 
enhanced version of RUDP 


Aeronautical communications involve layer 2 (Media Access Control (MAC) layer) congestion 
control mechanisms such as L-DACS. Therefore, the motivation behind removing the 
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congestion control methods from the transport layer (layer 4) is to prevent any further 
decrease of the performance in case the two layers mechanisms clash. Further, in this case, 
it makes more sense to move the congestion control to the MAC layer since they have the 
knowledge about the links properties and thus there is no need for cross-layer communication. 
Therefore, reducing system complexity. 

Furthermore, in (Ehammer, Graup! & Rokitansky, 2009), it was shown that the WXGRAPH 
message on the FW link (sized 21 kilobytes) is the one that is congesting the network due to 
its large size compared to the other services. One proposal could be, the implementation of 
a dual stack. Where TCP takes care of transmitting the messages from this service and keeps 
the others of small sizes for the new protocol. 


6. System dimensioning 


The requirements of the aeronautical traffic mandate a certain behavior from the lower layers. 
This behavior is governed by the properties offered by the system. This section will elaborate 
more on the aeronautical traffic properties. Additionally, some recommendations on the 
system properties will be derived. 


6.1 Aeronautical traffic properties 

As described in Section 2, messages generated by aeronautical services vary in size, 
inter-arrival times and latency requirements. These variations do not only occur between 
two different airspace domains or links (A/G and G/A links) but also within the same 
transport layer connection in case all services are multiplexed on the same transport session, 
as illustrated in Figure 4(b), which is an option from the transport layer session management 
mechanisms highlighted in Section 4. Further, Figures 9 and 10 show an aeronautical traffic 
pattern on the FW and the RT links, respectively. These plots show a sample test for two 
hours flight simulation in the TMA-ENR domain based on statistical expected traffic reports 
from (Rokitansky et al., 2008). 

Figures 9(a) and 10(a) show the size of the messages and their inter-arrival times from the 
application layer perspective. It is clear to see that the size of the messages fluctuates heavily 
especially on the FW link; on the RT link the largest measured message size is much smaller 
than the one on the FW channel; the inter-arrival times of these messages vary not only among 
the different services but also within every service as well. Nevertheless, few services are 
generated periodically. 

Figures 9(b) and 10(b) represent the data flows of these aeronautical messages. These data 
flows can be described by means of the cumulative function D(t), defined as the number of 
bits seen on the flow in the time interval [0, t]: 


D(t) = Vili (5) 


where l; is the length in bytes of the message i. 

The plots shown in Figure 11 represent the amount of bytes related to a specific service - 
identified by its size on the x-axis. For instance, the upper plot tells us that 80 % of the traffic 
data on the FW channel is generated by the WXGRAPH service (in which a single message 
amounts to 21 kilobytes). Additionally, all other services generate the remaining 20% of the 
data traffic. In other words, at the network layer this can be seen as a flow of packets with 
more than 80% of large sized datagrams and ca. 12% of packets less than the maximum 
transmission unit (MTU) size of 1500 bytes. 
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Fig. 9. Aeronautical traffic flow on the FW link in the TMA-ENR domain 
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Fig. 10. Aeronautical traffic flow on the RT link in the TMA-ENR domain 


On the other hand, only a single aeronautical service on the RT channel generates a message 
of size greater than the MTU size. However, this message can be fragmented only in two IP 
datagrams, if we also consider an MTU size similar to the one on the FW channel. Further, 
one can realize from the chart that almost 60 % of the traffic on the RT channel is generated by 
a service message of size 1000 bytes. 


6.2 System properties 

One of the major differences between an aeronautical application and a file transfer 
application, like FTP, is that avionics services are inelastic. This means that a service requires 
a certain minimum level of bandwidth and a certain maximum latency. In other words, an 
aeronautical application cannot adjust its rate, for example, to changeable network conditions. 
By contrast, an elastic application can adapt to network conditions. A file transfer, for instance, 
can easily adjust to different level of available bandwidth and latency as it has no severe 
latency requirements. 

Based on the above mentioned facts and in order for the system to function properly, it is 
fundamental to define some minimum system requirements such as serving rate and queues 
length. Figure 12 illustrates a simplified network architecture in which the ATS/ AOC client 
messages are buffered in a queue on the mobile router. This set-up is implemented on every 
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Fig. 11. Amount of data traffic generated by different ATM messages on the FW and RT 
channels, respectively 


aircraft. Access to the wireless link to connect to the ground station is granted through 
layer 2, in the protocol stack (MAC layer). At the other end, i.e. the ground segment, 
the corresponding servers use a single queue, at the ground station, to buffer the messages 
directed to all airplanes. 
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g RL bottleneck 

Ø queue | 


ATS Client [FL bottleneck] Ground Network 
queue 
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== -~ (bottleneck) ” 
A 


AOC Server 
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Fig. 12. Simplified network architecture 


To illustrate this, let’s assume that we have on the RT channel the service WXGRAPH, which 
is transmitting messages of a fixed size equal to 93 bytes with inter-arrival times illustrated 
in Figure 13(a). Figure 13(b), on the other hand, represents a possible realization of D(t), as 
defined in ( 5). 
Messages or packets (of fragmented messages) arrive (with a cumulative amount of data D(t)) 
at a buffer of size B and they are served in a First In First Out (FIFO) order with a rate r. The 
serving rate r exhibits the time needed for a message of size l to be transmitted on the link, in 
general: 

T (6) 
This scenario can be easily modeled using a leaky bucket as shown in Figure 14. A leaky 
bucket controller, according to (Boudec & Thiran, 2001), is a device that handles the data flow 
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Fig. 13. Properties of the WXGRAPH service on the RT link as reported in (Rokitansky et al., 
2008) 


D(t) as follows. There is bucket of fluid of size B. The bucket is initially empty (t = 0). The 
bucket has a hole and leaks at rate of r units of fluid per second when it is not empty. The 
data flow D(t) pours into the bucket in the time interval |tọ, t] an amount of fluid equal to the 
amount of data D(t) — D(to). Data that would cause the bucket to overflow is discarded. 


Fig. 14. Illustration of a leaky bucket model, pentagons represent the conformant data 


6.2.1 Serving rate: r 

Before deriving the minimum value of the required serving rate r, we need to make some 
assumptions such that the following work is clearer. First, let Gz describe a traffic generation 
stochastic process with emission rate Ag which is a stochastic variable with Az = E [Az] = 
p where fz is the average inter-arrival time. Further, assume that the emitted traffic is 


reaching the queue (the object to be studied) with the same rate, Az. So, Az is also an arrival 
rate process. Then, we denote by: 


G=} Gz (7) 
“4 
the total processes with an aggregate generation rate of: 
a=} àz (8) 
“4 
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where ¢ € ®, which is the number of processes. This follows: 
tr (9) 
4 


where À is the average aggregate arrival rate of the process G, and the average inter-arrival 
time is: 


= 
| 


= (10) 


At the first glance, we are interested in the behavior of a single process/service Gz, as if it is 
being served by a FIFO queue with serving rate rz. 
For a particular service Gz, if the number of arrivals in an interval [0, t] is aXe (t), then we can 
define: 

ag (t) 


Ag (t) = (11) 


as the arrival rate of the service Ç. Consequently, the average arrival rate and inter-arrival time 
of the service can be deduced from the following; by assuming that this limit exists: 


=z (12) 


The service rate rz allows us to determine the time needed for a service message of size Iz to be 
transmitted on the link, which is specified in (6). As illustrated in Figure 15(a), if the serving 
rate is low, then the upcoming messages will be buffered, until the current ones are processed, 
and therefore all message are delayed. 

Now, given the fixed message length Iz of a service ¢ and the probability density function 
(PDF) of the inter-arrival times, we can determine the minimum serving rate required for this 
service. The minimum required serving rate rz for service ¢ can be evaluated by: 


~ 


=£ 


G 


one (13) 


~ 


From Figure 15(b), this can be understood considering that rz is the average slope of the function 
Dz (t); it is clear that if the flow Dz (t) is served at a rate lower than rz, the distance between 
Dz (t) and the dotted line (offered load) will increase indefinitely for t + +o (see "waiting 
time" in Figure 15(a)). Thus, this distance remains bounded only if the serving rate is higher 
or equal to rz. In this case every message is being served the moment it enters the bucket; 
sometimes a message has to wait for some time in case the server is processing a previous job. 
This small waiting time is due to the fact that rz is derived based on the average inter-arrival 
time, therefore, it represents a lower bound on the serving rate for a single service ¢. 
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(a) Dz(t) with low serving rate rz; Gz is (b) Dz (t) with the minimum required serving 
WXGRAPH-RT rate rz; Gz is WXGRAPH-RT 


Fig. 15. Different serving rates for the Dz (t) of WXGRAPH-RT 


The estimation of the minimum required rate for an aggregation G of traffic sources can be 
similarly analyzed. If the total number of arrivals of the G service in the interval [0, t] is 
denoted by a (t) = Y¢ aç (t), then from (11), the total arrival rate is: 


a a(t) 
t 
Lic ag (t) 


t 
= us (t) (14) 


A (t) 


in which, if we assume that for every € € Ẹ all limits as in (12) exist, as t approaches +00, we 
obtain the average of the aggregate arrival rate: 


= an (5 


| 

5 
M 

> 
IN 


| 
M 

J 

> 
IN 


= 3 Az (t) (15) 


which as t — +00 converges to 


(16) 
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It follows that we can denote the average message size I for the aggregate process G as: 


A 
7 ¢ 
Ek (17) 


which is basically dependent on the average arrival rate of every service. 
Finally, the overall minimum required serving rate r for the aggregation of all the services 
Ç € Mis: 


1 why 

=À. gia 
Z 

Ag +e 


which is simply the aggregate serving rate of all services € € ©. 


6.2.2 Buffer size: B 

The buffer size B plays a vital role in aeronautical communications. It determines, besides 
the serving rate, the maximum waiting time that can be introduced by a queue also the 
probability to drop packets because of an overflow, i.e. the dropping probability. If B is 
very large, then a message/packet will experience a long waiting time that will affect the 
latency requirements of the service but a low dropping probability. Conversely, a small B will 
result in packets / messages being dropped whenever the buffer is full; thus, a higher dropping 
probability, but lower waiting time. 

Also, starting the evaluation for a single process served at rate rz, the waiting time of a packet, 
arriving at time t, in the queue is: 


Tw, (t) = (19) 


where bz (t) is the queue size at time t, i.e. Dz (t) — rg - t, see Figure 15(a). 
Assuming that the limit as t approaches +o exists for every service £ € ®, we can determine 
the expected waiting time per service message in the buffer as: 


co => lin F f if Tw, (x (20) 


which is independent of the used queueing model. Further, the average queue length for 
service Ç can be represented by: 


bp = lim = + [be be (x (21) 


t—+o t 


If the last two limits in (20) and (21) exist, then the Little’s theorem from (Kleinrock, 1975) 
states that the average buffer length in a queueing system can be rewritten as a function of the 
average process arrival rate times the average waiting time: 


bz = Az . Tw; (22) 
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Equation (22) describes an average queue size for the service ¢. For this single service, the 
queueing system could be modeled as M/D/1 where M refers to memoryless arrival rate 
and D stands for deterministic serving rate since the for a single service the message size Iz is 
constant, which implies a constant serving time per message. 

On the other hand, the aggregation of multiple services into a single queue allows the usage of 
a model with general serving time distribution, i.e. M/G/1, for which the size of the messages 
vary accordingly. 

The above mentioned models describe a queue with a length that can grow indefinitely. 
Therefore, to limit it with a certain buffer size B, the queueing model M/G/1/B could 
be implemented. This assumes that the aggregate arrival rate of the services has Poisson 
distribution, as proposed in the (EUROCONTROL & FAA, 2007). Clearly, for a finite buffer 
size B, the queue cannot accommodate all the messages arriving from the services because of 
their stochastic property. This is illustrated in Figure 16. As it can be clearly seen that not all of 
the total arrivals (A) are being buffered since the queue can reject arrivals when the buffer is 
full. Thus, arrivals noted by (Ae) denotes the rate of entering the system when the buffer is not 
full whereas (A4) indicates the rate of not entering the system because of the unavailability of 


resources. 
on G 


A Finite buffer size: B 
d 


Fig. 16. Illustration of a queue with limited size B and dropping probability 


The work in literature about queueing systems, such as in (Kleinrock, 1975) and (Smith, 2004), 
allows the derivation of the dropping probability as a function of arrival rate, buffer size 
and serving rate. This helps in designing a system that takes the latency requirements of 
the services into consideration and with minimum losses. 


7. Conclusions 


The requirements of a simple but reliable transport layer protocol for the safety critical ATM 
services like ATS and AOC have been discussed. The basic assumption that draws the 
design phase of this study was based on a priori recommendations. The new protocol to be 
designed has to address two goals; first, take out some algorithms of TCP that complicate its 
operation and add overhead, specifically congestion and flow control plus session initiation 
and shutdown procedures. Secondly, cope with the pattern of the aeronautical traffic, which 
is different from the Internet traffic like FTP, for example. Within this study, some drawbacks 
of using TCP for aeronautical services were highlighted and some protocol enhancements for 
RUDP to be an alternative solution to overcome these weakness points of TCP have been 
recommended. Furthermore, the system properties in terms of service rate and buffer sizes 
on both ESs were discussed. 
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